Each router reduces this hop limit by one, and the packet is finally discarded when the hop limit becomes 0. It is the responsibility of the host transmitting an IPv6 packet to set a hop limit for every IPv6 packet is transmitted.
The hop limit can be set in two ways: (i) by a system administrator for the host, or (ii) from the current hop limit of the interface via which this packet is to be transmitted. The current hop limit of the interface is maintained and updated from information in “Router Advertisement” messages. A “Router Advertisement” message is generated in response to a “Router Solicitation” message from the host, or when there if is an update in the network topology. The latter case is very common when an IPv6 address is configured in “Auto-configuration” or “DHCPv6” modes. However, if a router goes down, a flood of “Router Advertisement” messages can be generated in the network, causing frequent update of the current hop limit of an interface. It is therefore very important to set the 8-bit hop limit value for each and every packet in a fast and efficient way that can sustain a packet rate of millions of packets a second, and can scale to thousands of Transmission Control Protocol (TCP) connections that a host may need to handle.
A previous approach to the problem is to look up the “current hop limit” from the interface in the routing table. However, this doesn't scale for performance, because an expensive routing table lookup is required for transmission of each and every packet. Another approach is to have a cache for the routing table of every TCP flow on a per CPU basis (also known as flow table in literature). A routing table lookup can be performed against the flow table. The flow table can be invalidated periodically to avoid being stale. Though this approach is suitable for finding a route, it is not reliable for looking up “current hop count”. This is because if a stale current hop count value is set from the cache, it may lead to a packet getting dropped by a router.